The infrastructure of the Session Initiation Protocol (SIP) is defined in IETF RFC3261 (Rosenberg et al., June 2002). In general, the SIP is an application-layer control (signaling) protocol for creating, modifying and terminating sessions with one or more participants. The sessions can include Internet telephone calls, multimedia distribution and multimedia conferences. SIP invitations used to create sessions carry session descriptions that allow participants to agree on a set of compatible media types. SIP makes use of elements called proxy servers to help route requests to the user's current location, authenticate and authorize users for services, implement provider call-routing policies and provide features to users. SIP also provides a registration function that allows users to upload their current locations for use by proxy servers. SIP runs on top of several different transport protocols.
In “SIP-Specific Event Notification”, A. Roach, RFC 3265, July 2002 (referred to hereafter simply as RFC 3265), there is described a SIP event framework to enable event-based information provisioning to any node in the Internet. This procedure is expected to become a key element within the SIP infrastructure. Examples of this kind of information are presence, location information, content/service availability, or access-controlled SIP events, as described in several of the above-referenced related patent applications.
As is discussed in RFC 3265, the general concept is that entities in the network can subscribe to resource or call state for various resources or calls in the network, and those entities (or entities acting on their behalf) can send notifications when those states change. A typical flow of messages would be:
SubscriberNotifier|-----SUBSCRIBE---->|Request state subscription|<-------200--------------|Acknowledge subscription|<------NOTIFY---------|Return current state information|--------200------------->|Acknowledge|<------NOTIFY--------|Return current state information|--------200------------->|Acknowledge
Subscriptions are expired and must be refreshed by subsequent SUBSCRIBE messages.
Several useful definitions include the following:
Event Package: An event package is an additional specification which defines a set of state information to be reported by a notifier to a subscriber. Event packages also define further syntax and semantics based on the framework defined by RFC 3265 that are required to convey such state information.
Event Template-Package: An event template-package is a special kind of event package which defines a set of states which may be applied to all possible event packages, including itself.
Notification: Notification is the act of a notifier sending a NOTIFY message to a subscriber to inform the subscriber of the state of a resource.
Notifier: A notifier is a user agent which generates NOTIFY requests for the purpose of notifying subscribers of the state of a resource. Notifiers typically also accept SUBSCRIBE requests to create subscriptions.
State Agent: A state agent is a notifier which publishes state information on behalf of a resource; in order to do so, it may need to gather such state information from multiple sources. State agents always have complete state information for the resource for which they are creating notifications.
Subscriber: A subscriber is a user agent which receives NOTIFY requests from notifiers; these NOTIFY requests contain information about the state of a resource in which the subscriber is interested. Subscribers typically also generate SUBSCRIBE requests and send them to notifiers to create subscriptions.
Subscription: A subscription is a set of application state associated with a dialog. This application state includes a pointer to the associated dialog, the event package name, and possibly an identification token. Event packages will define additional subscription state information. By definition, subscriptions exist in both a subscriber and a notifier.
Subscription Migration: Subscription migration is the act of moving a subscription from one notifier to another notifier.
The SUBSCRIBE method is used to request current state and state updates from a remote node.
J. Rosenberg has defined in “A Watcher Information Event Template-Package for the Session Initiation Protocol (SIP)”, draft-ietf-simple-winfo-package-05.txt, Jan. 31, 2003, a watcher information template-package for the SIP event framework. Watcher information in this context refers to a set of users that are subscribed to a particular resource within a particular event package. Watcher information changes dynamically as users subscribe, unsubscribe, are approved, or are rejected. A user can subscribe to this information, and therefore can learn of changes to this information. This particular event package is referred to as a template-package, as it can be applied to any event package, including itself.
The SIP event framework as presented in RFC 3265, is a technique to provide context information in general. For example, the SIP presence provides a particular piece of context information, using a particular SIP event package. However, current subscription solutions for SIP events, such as for SIP presence, watcherinfo, and even call-state information, only allow for subscription to state information that is associated with a particular resource, where the particular resource is addressed as a SIP URI. For example, a subscription to a presence event is bound to a so-called presentity, representing the user to which the presence information is associated. Hence, when subscribing to state information, the subscriber subscribe to state information of a particular, a priori known resource (addressed through the SIP URI). At present, it is not possible to subscribe to state information that has been derived from a set of state information associated to certain URIs.
Based on the foregoing, it may be appreciated that with the current subscription model of SIP questions (queries) such as:
“Which persons (resources) are in a meeting, the meeting being in a particular location?” and
“Which persons (resources) are at work right now, with work location Boston, and are not busy?”
can only be answered by subscribing to all available and relevant resources at a particular SIP event server, and upon reception of notifications that are related to the required state information, by executing an appropriate application logic at the subscriber in order to determine the set of resources that would fulfil the given constraints. This is necessary since as currently defined SIP event subscriptions are bound to particular resources, e.g., a subscription to a SIP presence event is bound to the presentity.
It can be readily seen that such a solution is not scalable if one were to assume, by example, a fairly large domain such as a mobile operator, since such a solution could easily overburden the subscriber with respect to maintaining the subscriptions and handling incoming notifications, as well as the SIP event server with respect to creating such large numbers of subscriptions. Such a solution could also easily fail, for example by leaving out certain domains that are hosted at the particular SIP event server but that are unknown to the subscriber.
That is, the subscriber might “miss” certain resources by simply not knowing or not being aware of the relevance of the particular resource for the answer to the query. For example, a particular SIP event server may host event information for resources in two different domains, “domain1.com” and “domain2.com”. Assume in this case that the subscriber is aware of the hosting of the first domain but not of the second domain. Hence, the subscriber would not subscribe to the relevant resources of the second domain and could therefore potentially “miss” important information.
Assuming the hosting of particular state information at a SIP event server for a multiplicity of resources at a certain time, it would be desirable to have a way to formulate the exemplary SIP queries given above within a single subscription, with the queries operating on an available set of information within the SIP event server. For example, since usually there exists presence information for a large set of presentities at a SIP presence server, it would be desirable to perform queries such as those above on the set of presentities within a single subscription. Prior to this invention, these needs were unfulfilled.